On 01/08/2014 08:56 AM, Simon Riggs wrote:
Current freesapce code gives a new block insert target (NBT) from
anywhere in table. That isn't very useful with bigger tables and it
would be useful to be able to specify different algorithms for
producing NBTs.
I've actually been surprised how little
On 8th Jan, 2014, Amit Kapila Wrote
>
> > Add a new "eager" synchronous mode that starts out synchronous but
> > reverts to asynchronous after a failure timeout period
> >
> > This would require some type of command to be executed to alert
> > administrators of this change.
> >
> > http://archives
Current freesapce code gives a new block insert target (NBT) from
anywhere in table. That isn't very useful with bigger tables and it
would be useful to be able to specify different algorithms for
producing NBTs.
ALTER TABLE foo WITH (freespace = );
Three simple and useful models come to mind
On 01/08/2014 02:00 PM, Craig Ringer wrote:
> I'm not sure I understand how this would work in the face of multiple
> levels of nesting s.b. views. Are you thinking of doing recursive expansion?
Never mind, that part is clearly covered in the patch.
--
Craig Ringer http://ww
> I've been thinking about this some more and I don't think you can
> avoid the need to remap vars and attrs.
I agree. I was hoping to let expand_targetlist / preprocess_targetlist
do the job, but I'm no longer convinced that'll do the job without
mangling them in the process.
> AIUI, your modifi
On Tue, Jan 7, 2014 at 11:36 AM, Heikki Linnakangas
wrote:
> Hmm. The xlogdump indeed shows that the order of 'clean' and 'visible' is
> incorrect, but I don't immediately see how that could cause the PANIC. Why
> is the page uninitialized in the standby? If VACUUM is removing some dead
> tuples f
On Wed, Nov 13, 2013 at 6:39 PM, Rajeev rastogi
wrote:
> Add a new "eager" synchronous mode that starts out synchronous but reverts
> to asynchronous after a failure timeout period
>
> This would require some type of command to be executed to alert
> administrators of this change.
>
> http://arch
Hello,
tgl> I'm pretty sure that IsA test prevents the optimization from ever firing.
Thank you.
tgl> But aside from hasty typos,
Oops! I've picked up wrong node. It always denies pathkeys extension.
| !IsA(member, Var))
is a mistake of the following.
| !IsA(member->em_expr, Var))
tgl> is t
Below attached patch is implementing following todo item..
machine-readable pg_controldata?
http://www.postgresql.org/message-id/4b901d73.8030...@agliodbs.com
Possible approaches:
1. Implement as backend function and provide a view to user.
- But In this approach user can only get
Below attached patch is implementing following todo item..
machine-readable pg_controldata?
http://www.postgresql.org/message-id/4b901d73.8030...@agliodbs.com
Possible approaches:
1. Implement as backend function and provide a view to user.
- But In this approach user can only get
On Wed, Jan 8, 2014 at 1:25 AM, Heikki Linnakangas
wrote:
> On 01/07/2014 05:20 PM, Tom Lane wrote:
>>
>> David Rowley writes:
>>>
>>> I think it will be like Andres said up thread, to stop multiple
>>> evaluations
>>> of the expression passed to the macro.
>>
>>
>> Exactly. We are not going to
On Tue, Jan 7, 2014 at 2:46 AM, Robert Haas wrote:
> On Mon, Jan 6, 2014 at 4:04 PM, james wrote:
>> The point remains that you need to duplicate it into every process that
>> might
>> want to use it subsequently, so it makes sense to DuplicateHandle into the
>> parent, and then to advertise that
I wrote:
> There's probably some overhead from traversing advance_transition_function
> for each row, which your version wouldn't have done. 15% sounds pretty
> high for that though, since advance_transition_function doesn't have much
> to do when the transition function is non strict and the stat
Robert Haas wrote:
> On Mon, Jan 6, 2014 at 9:40 PM, Etsuro Fujita
> wrote:
> > Thank you for taking time to look at this patch. The peak memory
> > usage for the discarded bitmap *can* be reflected in the number
> > displayed for the bitmap heap scan by the following code in tbm_union()
> or tbm
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> The key reason for that was, and remains, not having the
> Tom> behavior hard-wired in nodeAgg; I believe that this design
> Tom> permits things to be accomplished in aggregate implementation
> Tom> functions that would not have been po
On Tue, Jan 7, 2014 at 6:54 AM, Andres Freund wrote:
>> Maybe it makes sense to have such a check #ifdef'ed out on most builds
>> to avoid extra overhead, but not having any check at all just because we
>> trust the review process too much doesn't strike me as the best of
>> ideas.
>
> I don't thi
On Tue, Jan 7, 2014 at 5:36 PM, Heikki Linnakangas
wrote:
> On 01/07/2014 07:15 PM, Matheus de Oliveira wrote:
>
>> Hi folks,
>>
>>
>> On Fri, Dec 13, 2013 at 9:47 AM, Heikki Linnakangas <
>> hlinnakan...@vmware.com
>>
>>> wrote:
>>>
>>
>> lazy_vacuum_page() does this:
>>>
>>> 1. START_CRIT_SECTI
> "Tom" == Tom Lane writes:
>> Furthermore, I can't help noticing that the increased complexity
>> has now pretty much negated your original arguments for moving so
>> much of the work out of nodeAgg.c.
Tom> The key reason for that was, and remains, not having the
Tom> behavior hard-wir
On 2014-01-07 21:36:31 +0200, Heikki Linnakangas wrote:
> >2088220 ... Heap2 ... 24/ 192, ... lsn: 2BC/46AB8B20 ... desc: clean:
> >rel 1663/883916/151040222; blk 1073 remxid 107409880
> >2088221 ... Heap2 ... 20/52, ... lsn: 2BC/46AB8BE0 ... desc: visible:
> >rel 1663/883916/151040222; blk
Andrew Gierth writes:
> Retesting with your changes shows that the gap is down to 15% but still
> present:
There's probably some overhead from traversing advance_transition_function
for each row, which your version wouldn't have done. 15% sounds pretty
high for that though, since advance_transit
> "Tom" == Tom Lane writes:
>> Initial tests suggest that your version is ~40% slower than ours on
>> some workloads.
Tom> I poked at this a bit with perf and oprofile, and concluded that
Tom> probably the difference comes from ordered_set_startup()
Tom> repeating lookups for each group
AK wrote:
> So if I am reading the data and then commit, I should be always
> fine, correct?
If a serializable transaction successfully commits, that means that
all data read within that transaction can be trusted.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Com
Mark Dilger writes:
> Would it make sense for this to just be part of 'make check'?
Probably not, as (I imagine) it will take quite a bit longer than
"make check" does today. People who are not working on replication
related features will be annoyed if a test cycle starts taking 10X
longer than
On Tuesday, January 7, 2014 7:29 AM, Tom Lane wrote:
Heikki Linnakangas writes:
> Another idea would be to do something like chroot, but more lightweight,
> using FUSE, private mount namespaces, or cgroups.
I thought the goal here was to have a testing framework that (a) is
portable to ev
Thom Brown escribió:
> On 7 January 2014 15:47, Robert Haas wrote:
> > On Mon, Jan 6, 2014 at 9:37 PM, Hafez Kamal wrote:
> >> Issue #10 is now available!
> >
> > What does any of this have to do with the purpose of the pgsql-hackers
> > mailing list, namely development of the PostgreSQL database
Kyotaro HORIGUCHI writes:
> The following modification to v7 does this.
> =
> diff --git a/src/backend/optimizer/path/pathkeys.c
> b/src/backend/optimizer/path/pathkeys.c
> index 380f3ba..233e21c 100644
> --- a/src/backend/optimizer/path/pathkeys.c
> +++ b/src/backend/optimizer/path/path
Regarding this: >> So what does this have to do with relying on the results
of read-only
transactions that abort? Well, what if you had instead had R ROLLBACK
instead of COMMIT -- maybe because you expected ROLLBACK and COMMIT to
be equivalent for transactions that don't modify the database, or
On 01/07/2014 05:20 PM, Tom Lane wrote:
David Rowley writes:
I think it will be like Andres said up thread, to stop multiple evaluations
of the expression passed to the macro.
Exactly. We are not going to risk multiple evals in a macro as commonly
used as elog/ereport; the risk/benefit ratio
AK wrote:
> Session 1. Setting up:
>
> CREATE TABLE cars(
> license_plate VARCHAR NOT NULL,
> reserved_by VARCHAR NULL
> );
> INSERT INTO cars(license_plate)
> VALUES ('SUPRUSR'),('MIDLYPH');
>
> Session 2: W1
>
> BEGIN ISOLATION LEVEL SERIALIZABLE;
>
> UPDATE cars SET reserved_by = 'Julia'
>
On 01/07/2014 07:15 PM, Matheus de Oliveira wrote:
Hi folks,
On Fri, Dec 13, 2013 at 9:47 AM, Heikki Linnakangas
wrote:
lazy_vacuum_page() does this:
1. START_CRIT_SECTION()
2. Remove dead tuples from the page, marking the itemid's unused.
3. MarkBufferDirty
4. if all remaining tuples on t
Dan Ports wrote:
> On Mon, Jan 06, 2014 at 05:14:12PM -0800, AK wrote:
> If you try this, it'll cause a serialization failure on the line
> marked with a '!'. W1 saw (1,0) in the table, so W1 appears to
> have executed before W2. But R saw both (1,1) and (2,0) in the
> table, and that has to be a
Emre Hasegeli writes:
> I get assertion failure on initsplan.c line 1325 while executing following
> query
> on HEAD (edc43458d797a5956f4bf39af18cf62abb0077db). It works fine
> without --enable-cassert.
> update subscriber set properties = hstore(a) from (select firstname,
> lastname from player
Magnus Hagander writes:
> Applied a fairly heavily edited version of this one. I also backpatched it
> to 9.1 and up.
Thanks a lot!
Did some reviewing and re-testing here, I like using DataDir and
IS_DIR_SEP better than what I did, of course ;-)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.
Hi folks,
On Fri, Dec 13, 2013 at 9:47 AM, Heikki Linnakangas wrote:
> lazy_vacuum_page() does this:
>
> 1. START_CRIT_SECTION()
> 2. Remove dead tuples from the page, marking the itemid's unused.
> 3. MarkBufferDirty
> 4. if all remaining tuples on the page are visible to everyone, set the
> a
On Jan7, 2014, at 00:38 , Jim Nasby wrote:
> This email and the previous one are an awesome bit of information,
> can we add it to the docs somehow? Even if it's just dumping the
> emails into a wiki page and referencing it?
Most of what I wrote there can be found in README-SSE, I think,
under "A
I get assertion failure on initsplan.c line 1325 while executing following query
on HEAD (edc43458d797a5956f4bf39af18cf62abb0077db). It works fine
without --enable-cassert.
update subscriber set properties = hstore(a) from (select firstname,
lastname from player where player.id = subscriber.id) as
On Tue, Jan 7, 2014 at 5:43 PM, Andres Freund wrote:
> On 2014-01-07 17:40:07 +0100, Magnus Hagander wrote:
> > On Tue, Dec 24, 2013 at 1:24 PM, Andres Freund >wrote:
> >
> > > On 2013-12-23 18:28:51 +0100, Magnus Hagander wrote:
> > > > On Dec 19, 2013 12:06 AM, "Andres Freund"
> > > wrote:
> >
On 2013-12-12 16:49:33 +0100, Andres Freund wrote:
> On 2013-12-12 10:01:21 -0500, Robert Haas wrote:
> > On Thu, Dec 12, 2013 at 7:04 AM, Andres Freund
> > wrote:
> > > As far as I have been thinking of, this would be another catalog table
> > > like
> > > pg_decoding_plugin(oid, dpname name, d
On 2014-01-07 17:40:07 +0100, Magnus Hagander wrote:
> On Tue, Dec 24, 2013 at 1:24 PM, Andres Freund wrote:
>
> > On 2013-12-23 18:28:51 +0100, Magnus Hagander wrote:
> > > On Dec 19, 2013 12:06 AM, "Andres Freund"
> > wrote:
> > > >
> > > > Hi Magnus,
> > > >
> > > > It looks to me like the pat
Christoph Berg writes:
> A customer recently upgraded their jdbc driver from 8.4 to 9.2. This
> enabled the binary wire protocol (effectively between 9.1 and 9.2).
> They reported that single precision values inserted into a
> numeric(10,2) column were suddenly rounded wrongly, i.e. 1.18 was
>
On Tue, Dec 24, 2013 at 1:24 PM, Andres Freund wrote:
> On 2013-12-23 18:28:51 +0100, Magnus Hagander wrote:
> > On Dec 19, 2013 12:06 AM, "Andres Freund"
> wrote:
> > >
> > > Hi Magnus,
> > >
> > > It looks to me like the path to do_pg_start_backup() outside of a
> > > transaction context comes
On 2014-01-07 11:08:22 -0500, Tom Lane wrote:
> Andres Freund writes:
> > To the point that I am not seing the problem right now. I am not
> > proposing to get rid of statically assigned oids in pg_type et al.. The
> > references to procs mostly seem to be typed 'regproc' so there aren't
> > many
On Mon, Jan 6, 2014 at 9:40 PM, Etsuro Fujita
wrote:
> Robert Haas wrote:
>> I spent some time looking at this tonight. I don't think the value that
>> is displayed for the bitmap memory tracking will be accurate in complex
>> cases. The bitmap heap scan may sit on top of one or more bitmap-and
On Thu, Jan 2, 2014 at 2:06 PM, Dimitri Fontaine wrote:
> Magnus Hagander writes:
> > We can't get away with just comparing the relative part of the pathname.
> > Because it will fail if there is another path with exactly the same
> length,
> > containing the tablespace.
>
> Actually… yeah.
>
> >
AK wrote:
> I cannot have a read-only transaction fail because of
> serialization anomalies. Can someone show me a working example
> please?
A common case is a read-only transaction reading a closed batch
without seeing all of its entries.
http://wiki.postgresql.org/wiki/SSI#Read_Only_Transacti
Andres Freund writes:
> To the point that I am not seing the problem right now. I am not
> proposing to get rid of statically assigned oids in pg_type et al.. The
> references to procs mostly seem to be typed 'regproc' so there aren't
> many references to function's oids.
*Some* of them are typed
On 7 January 2014 15:47, Robert Haas wrote:
> On Mon, Jan 6, 2014 at 9:37 PM, Hafez Kamal wrote:
>> Issue #10 is now available!
>
> What does any of this have to do with the purpose of the pgsql-hackers
> mailing list, namely development of the PostgreSQL database server?
We had a similar email
On Mon, Jan 6, 2014 at 9:37 PM, Hafez Kamal wrote:
> Issue #10 is now available!
What does any of this have to do with the purpose of the pgsql-hackers
mailing list, namely development of the PostgreSQL database server?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Pos
On 2014-01-07 10:27:14 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Another idea would be to do something like chroot, but more lightweight,
> > using FUSE, private mount namespaces, or cgroups.
>
> I thought the goal here was to have a testing framework that (a) is
> portable to ever
Heikki Linnakangas writes:
> Another idea would be to do something like chroot, but more lightweight,
> using FUSE, private mount namespaces, or cgroups.
I thought the goal here was to have a testing framework that (a) is
portable to every platform we support and (b) doesn't require root
privile
On 2014-01-07 10:04:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think we also should auto-assign the oids for pg_proc (and some other
> > tables) rows if we go there.
>
> -1 ... you've evidently not built any opclasses lately.
True. Not sure if I ever built one, but when playing arou
David Rowley writes:
> I think it will be like Andres said up thread, to stop multiple evaluations
> of the expression passed to the macro.
Exactly. We are not going to risk multiple evals in a macro as commonly
used as elog/ereport; the risk/benefit ratio is just too high.
I don't see anything
Andres Freund writes:
> I think we also should auto-assign the oids for pg_proc (and some other
> tables) rows if we go there.
-1 ... you've evidently not built any opclasses lately.
Yeah, we could probably improve the bootstrap infrastructure enough to not
need literal OIDs in so many places in
A customer recently upgraded their jdbc driver from 8.4 to 9.2. This
enabled the binary wire protocol (effectively between 9.1 and 9.2).
They reported that single precision values inserted into a
numeric(10,2) column were suddenly rounded wrongly, i.e. 1.18 was
inserted as 1.20, while that
From: "Bruce Momjian"
On Sun, Jan 5, 2014 at 04:40:17PM +0900, MauMau wrote:
Then, as a happy medium, how about disabling message localization
only if the client encoding differs from the server one? That is,
compare the client_encoding value in the startup packet with the
result of GetPlatfo
That was probably me. I'll look into it.
> On Jan 6, 2014, at 11:40 PM, Tom Lane wrote:
>
> Bruce Momjian writes:
>>> On Sun, Dec 29, 2013 at 02:48:21AM -0500, Tom Lane wrote:
>>> 3. pg_upgrade ignores the fact that pg_resetxlog failed, and keeps going.
>
>> Does pg_resetxlog return a non-ze
On Jan7, 2014, at 09:45 , Heikki Linnakangas wrote:
> Overall, I'm leaning towards biting the bullet and always detoasting
> everything in master. Probably best to just leave the stable branches alone.
+1
The fact that de-TOAST-ing can happen lazily is, at least to me, an
implementation detail
On 2014-01-06 21:35:22 -0300, Alvaro Herrera wrote:
> Jim Nasby escribió:
> > On 1/6/14, 2:59 PM, Robert Haas wrote:
> > >On Mon, Jan 6, 2014 at 3:57 PM, Tom Lane wrote:
>
> > >>The point I'm making is that no such code should get past review,
> > >>whether it's got an obvious performance problem
On 2014-01-06 11:56:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think I am less concerned about pseudotypes.c than about bloating
> > pg_proc.h even further and about the annoyance of editing it - but I
> > guess that should rather be fixed by storing it in a more sensible
> > format a
Hello all,
when pg_ctl start is used to run PostgreSQL in a console window on
Windows, it runs in the background (it is terminated by closing the
window, but that is probably inevitable). There is one problem, however:
The first Ctrl-C in that window, no matter in which situation, will
cause
On 2014-01-07 10:45:24 +0200, Heikki Linnakangas wrote:
> Overall, I'm leaning towards biting the bullet and always detoasting
> everything in master. Probably best to just leave the stable branches alone.
If we're doing something coarse grained as this, I agree, it should be
master only.
I perso
Hello.
Since the last discussion about it
(http://www.postgresql.org/message-id/cadyhksugp6ojb1pybtimop3s5fg_yokguto-7rbcltnvaj5...@mail.gmail.com),
I
finally managed to implement row triggers for foreign tables.
The attached patch does not contain regression tests or documentation yet, a
revis
On 2014-01-06 20:51:57 -0500, Robert Haas wrote:
> On Mon, Jan 6, 2014 at 7:50 PM, Jim Nasby wrote:
> > On 1/4/14, 8:19 AM, Robert Haas wrote:
> >> Also, while multixactid_freeze_min_age should be low, perhaps a
> >> million as you suggest, multixactid_freeze_table_age should NOT be
> >> lowered t
On Mon, Jan 06, 2014 at 05:14:12PM -0800, AK wrote:
> Also I cannot reproduce a scenario when "applications must not depend on
> results read during a transaction that later aborted;". In this example the
> SELECT itself has failed.
> Can you show an example where a SELECT completes, but the COMMIT
On 01/06/2014 07:12 PM, Mark Dilger wrote:
The reason I was going to all the trouble of creating
chrooted environments was to be able to replicate
clusters that have tablespaces.
You can remove and recreate the symlink in pg_tblspc directory, after
creating the cluster, to point it to a differ
On 01/06/2014 08:29 PM, Andres Freund wrote:
On 2014-01-06 12:40:25 -0500, Robert Haas wrote:
On Mon, Jan 6, 2014 at 11:47 AM, Andres Freund wrote:
On 2014-01-06 11:08:41 -0500, Robert Haas wrote:
Yea. But at least it would fail reliably instead of just under
concurrency and other strange circ
On Thu, Jan 2, 2014 at 11:34 PM, Bernd Helmle wrote:
>
>
> --On 1. Januar 2014 23:53:46 +0100 Dimitri Fontaine
> wrote:
>
>> Hi,
>>
>> As much as I've seen people frown upon $subject, it still happens in the
>> wild, and Magnus seems to agree that the current failure mode of our
>> pg_basebackup
On Mon, Jan 6, 2014 at 5:37 PM, Gabriele Bartolini
wrote:
> Hi Fabrizio,
>
> Il 05/01/14 20:46, Fabrizio Mello ha scritto:
>> I don't see your code yet, but I would like to know if is possible to
>> implement this view as an extension.
> I wanted to do it as an extension - so that I could backport
On Sun, Jan 5, 2014 at 3:49 PM, MauMau wrote:
> Could you confirm again and tell me what problem is happening?
FWIW, I just quickly tested those two patches independently and got
them correctly applied with patch -p1 < $PATCH on master at edc4345.
They compiled and passed as well make check.
Regar
69 matches
Mail list logo
