Hi,
It's regarding a Todo item of "Bit data type header reduction" in some
cases. The header contains two parts. 1) The varlena header is
automatically converted to 1 byte header from 4 bytes in case of small
data. 2) The bit length header called "bit_len" to store the actual bit
length which is
On Tue, Feb 25, 2014 at 10:02 AM, Alvaro Herrera
wrote:
> While we're messing with this, I wonder if there's any way to have
> infomask and infomask2 displayed in hex format rather than plain int
> without having to specify that in every query. I'm not well known for
> being able to do such conve
On Mon, Feb 24, 2014 at 11:34 PM, Alvaro Herrera
wrote:
>
> Andres Freund escribió:
> > On 2014-02-24 17:53:31 +0900, Michael Paquier wrote:
> > > On Sun, Feb 23, 2014 at 6:09 AM, Alvaro Herrera
> > > wrote:
> > >
> > > > Michael Paquier escribió:
> > > > > Hi all,
> > > > >
> > > > > Please find
> > /* Hook for plugins to add custom join path, in addition to default
> > ones */ typedef void (*add_join_path_hook_type)(PlannerInfo *root,
> > RelOptInfo *joinrel,
> > RelOptInfo *outerrel,
> >
On 04 February 2014 14:38, Myself wrote:
>
> On 4th February 2014, Christian kruse Wrote:
> > On 04/02/14 12:38, Fujii Masao wrote:
> > > ISTM that the phrase "Request queue" is not used much around the
> lock.
> > > Using the phrase "wait queue" or Simon's suggestion sound better to
> > at least
This is a small patch to improve comments in tablecmds.c. Please find
attached a patch.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 08b037e..ed9d206 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/comm
committed
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
While we're messing with this, I wonder if there's any way to have
infomask and infomask2 displayed in hex format rather than plain int
without having to specify that in every query. I'm not well known for
being able to do such conversions off the top of my head ...
(Not that it's this patch' res
On Tue, Feb 25, 2014 at 12:41 AM, Robert Haas wrote:
> On Wed, Feb 19, 2014 at 8:27 PM, Michael Paquier
> wrote:
> > On Thu, Feb 20, 2014 at 8:55 AM, Andres Freund
> wrote:
> >> On 2014-02-19 12:47:40 -0500, Robert Haas wrote:
> >>> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
> >>> wrote:
On Tue, Feb 25, 2014 at 10:44 AM, Kouhei Kaigai wrote:
> Thanks for your testing,
>
> > Getting some compilation warnings while compiling the extension and also
> > I am not able to load the extension because of undefined symbol
> > "get_restriction_qual_cost".
> >
> It seems to me you applied onl
On 2014-02-24 15:20:13 -0800, Peter Geoghegan wrote:
> On Mon, Feb 24, 2014 at 3:17 PM, Andres Freund wrote:
> > TBH I don't care about torn pages during normal testing. I don't want to
> > suggest disabling it for real workloads with real data, just that it's
> > important to do so during develop
On Mon, Feb 24, 2014 at 3:17 PM, Andres Freund wrote:
> TBH I don't care about torn pages during normal testing. I don't want to
> suggest disabling it for real workloads with real data, just that it's
> important to do so during development/testing of WAL related code,
> because otherwise it will
On 2014-02-24 15:05:37 -0800, Peter Geoghegan wrote:
> On Mon, Feb 24, 2014 at 1:17 PM, Andres Freund wrote:
> > We somehow need to have a policy of testing changes to the WAL format
> > without full_page_writes. They hide bugs in replay far, far too often.
>
> What's the easiest way to get atomi
Hi,
On 2014-02-24 17:06:53 -0500, Robert Haas wrote:
> I still think pg_create_logical_replication_slot should be in slotfuncs.c.
Ok, I don't feel too strongly, so I can change it. I wanted to keep
logical/ stuff out of slotfuncs.c, but there's not really a strong
reason for that.
> I don't thin
On Mon, Feb 24, 2014 at 1:17 PM, Andres Freund wrote:
> We somehow need to have a policy of testing changes to the WAL format
> without full_page_writes. They hide bugs in replay far, far too often.
What's the easiest way to get atomic page writes at the FS level on
your laptop? ZFS or some data
On Mon, Feb 24, 2014 at 10:11 AM, Andres Freund wrote:
> Changes in this version include:
> * changed slot error handling log by introducing "ephermal" slots which
> get dropped on errors. This is the biggest change.
> * added quoting in the test_decoding output plugin
> * closing of a tight rac
On 2014-02-24 22:17:31 +0100, Andres Freund wrote:
> Those together explain the story. Note this bit:
>
> static void
> heap_xlog_lock(XLogRecPtr lsn, XLogRecord *record)
> {
> ...
> HeapTupleHeaderClearHotUpdated(htup);
> HeapTupleHeaderSetXmax(htup, xlrec->locking_xid);
> HeapTupleHe
Hi,
On 2014-02-24 17:55:14 -0300, Alvaro Herrera wrote:
> Greg Stark wrote:
> > I have a database where a a couple rows don't appear in index scans
> > but do appear in sequential scans. It looks like the same problem as
> > Peter reported but this is a different database. I've extracted all
> > t
On 02/24/2014 02:15 PM, Andrew Dunstan wrote:
Having had my schedule very seriously disrupted by the storm in the US
South East a week or so ago, I am finally getting back to being able
to devote some time to jsonb. I hope to have new patches available
today or tomorrow at the latest.
Here's a reformatted copy. I think this is the same bug as Peter G.
reported in
http://www.postgresql.org/message-id/CAM3SWZTMQiCi5PV5OWHb+bYkUcnCk=o67w0csswpvv7xfuc...@mail.gmail.com
I have a hunch that this is related to the heap_lock_updated business.
I haven't investigated yet.
Greg Stark
On 2014-02-20 13:25:35 +, Greg Stark wrote:
> rmgr: Heaplen (rec/tot):235/ 267, tx:5943845, lsn:
> FD/2F0A3640, prev FD/2F0A3600, bkp: , desc: insert: rel
> 1663/16385/212653; tid 13065/2
> lp | lp_off | lp_flags | lp_len | t_xmin | t_xmax | t_field3 |
> t_ctid | t_i
Alvaro Herrera writes:
> Bruce Momjian escribió:
>> Well, typmods are type-specific, so there is no official way to
>> calculate it. I would look at how an existing type uses typmod and copy
>> that.
> Our system is pretty neat. See a complex example here:
> https://github.com/postgis/postgis/b
On Mon, Feb 24, 2014 at 7:02 AM, Pavel Stehule wrote:
>
>
>
> 2014-02-23 21:32 GMT+01:00 Andres Freund :
>
> Hi,
>>
>> On 2014-02-23 20:04:39 +0100, Pavel Stehule wrote:
>> > There is relative few very long ProcArrayLocks lwlocks
>> >
>> > This issue is very pathologic on fast computers with more
Bruce Momjian escribió:
> On Sun, Feb 23, 2014 at 07:50:08AM +0330, Mohsen SM wrote:
> > Hello.
> > I have a new type similar to varchar.
> > I want to fine how did I can to calculate typemod
> > and where must I calculate typemod for this type.
>
> Well, typmods are type-specific, so there is no
On Sun, Feb 23, 2014 at 07:50:08AM +0330, Mohsen SM wrote:
> Hello.
> I have a new type similar to varchar.
> I want to fine how did I can to calculate typemod
> and where must I calculate typemod for this type.
Well, typmods are type-specific, so there is no official way to
calculate it. I would
On 02/24/2014 11:06 AM, Merlin Moncure wrote:
On Mon, Feb 24, 2014 at 9:08 AM, Merlin Moncure wrote:
On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure wrote:
I still find the phrasing "as jsonb is more efficient for most
purposes" to be a bit off Basically, the text json type is faster for
se
On Mon, Feb 24, 2014 at 07:23:50PM +0100, Andres Freund wrote:
> On 2014-02-24 13:16:39 -0500, Bruce Momjian wrote:
> > On Mon, Feb 24, 2014 at 07:09:29PM +0100, Andres Freund wrote:
> > > On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote:
> > > > On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Mom
On Mon, Feb 24, 2014 at 3:23 PM, Andres Freund
wrote:
> > > Thanks. It'd have been nice tho, to mention Fabrízio in the commit
> > > message as the patch's author.
> >
> > Uh, I was thinking of that, but I basically rewrote the patch from
> > scratch and changed its visible behavior, so I was worr
On 2014-02-24 13:16:39 -0500, Bruce Momjian wrote:
> On Mon, Feb 24, 2014 at 07:09:29PM +0100, Andres Freund wrote:
> > On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote:
> > > On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote:
> > > > As others, I am concerned about people being confus
On Mon, Feb 24, 2014 at 07:09:29PM +0100, Andres Freund wrote:
> On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote:
> > On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote:
> > > As others, I am concerned about people being confused when funny-looking
> > > trigger names suddenly appearin
On 2014-02-24 12:45:12 -0500, Bruce Momjian wrote:
> On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote:
> > As others, I am concerned about people being confused when funny-looking
> > trigger names suddenly appearing when you disable all table triggers.
> >
> > What I ended up doing i
On Mon, Feb 17, 2014 at 11:14:33AM -0500, Bruce Momjian wrote:
> On Sun, Feb 16, 2014 at 09:26:47PM -0500, Robert Haas wrote:
> > > So, would anyone like me to create patches for any of these items before
> > > we hit 9.4 beta? We have added autovacuum_work_mem, and increasing
> > > work_mem and m
2014-02-24 16:09 GMT+01:00 Andres Freund :
> On 2014-02-23 20:04:39 +0100, Pavel Stehule wrote:
> >354246.00 93.0% s_lock
> > /usr/lib/postgresql/9.2/bin/postgres
> > 10503.00 2.8% LWLockRelease
> > /usr/lib/postgresql/9.2/bin/postgres
> > 8802.00 2.3% LWLoc
On Sat, Feb 15, 2014 at 07:34:20PM -0500, Bruce Momjian wrote:
> On Sat, Feb 15, 2014 at 07:19:46PM -0500, Robert Haas wrote:
> > On Thu, Feb 13, 2014 at 10:55 AM, Bruce Momjian wrote:
> > > I have created the attached patch which removes many of the pre-8.0
> > > references, and trims some of the
On Mon, Feb 24, 2014 at 9:48 AM, Andres Freund wrote:
> On 2014-02-15 17:29:04 -0500, Robert Haas wrote:
>> On Fri, Feb 14, 2014 at 4:55 AM, Andres Freund
>> wrote:
>
>> + /*
>> +* XXX: It's impolite to ignore our argument and keep decoding until
>> the
>> +* current posit
On Wed, Feb 12, 2014 at 09:04:45PM -0500, Bruce Momjian wrote:
> As others, I am concerned about people being confused when funny-looking
> trigger names suddenly appearing when you disable all table triggers.
>
> What I ended up doing is to create a user and internal section when
> displaying dis
On Thu, Feb 20, 2014 at 7:27 PM, Jeremy Harris wrote:
> On 09/02/14 17:11, Jeremy Harris wrote:
>> On 06/02/14 18:21, Jeff Janes wrote:
>>> Did you try sorting already-sorted, reverse
>>> sorted, or pipe-organ shaped data sets? We will also need to test it on
>>> strings. I usually use md5(ran
On 02/24/2014 07:08 AM, Merlin Moncure wrote:
> On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure wrote:
>> I still find the phrasing "as jsonb is more efficient for most
>> purposes" to be a bit off Basically, the text json type is faster for
>> serialization/deserialization pattern (not just docu
On 13 February 2014 04:12, Craig Ringer wrote:
> On 02/11/2014 08:19 PM, Yeb Havinga wrote:
>
>> I compared output of psql -ef of the minirim.sql script posted earlier
>> in http://www.postgresql.org/message-id/52f54927.1040...@gmail.com
>> between v4 and v7.
>>
>> Not everything is ok.
>
>> +psql
On Fri, Feb 14, 2014 at 05:02:26PM -0500, Bruce Momjian wrote:
> On Thu, Feb 13, 2014 at 09:47:01PM -0500, Bruce Momjian wrote:
> > On Wed, Oct 16, 2013 at 02:17:11PM -0400, Bruce Momjian wrote:
> > > > > You can see the UTF8 case is fine because \n is considered greater
> > > > > than space, but i
On 20 February 2014 01:48, Florian Pflug wrote:
> On Jan29, 2014, at 13:45 , Florian Pflug wrote:
>> In fact, I'm
>> currently leaning towards just forbidding non-strict forward transition
>> function with strict inverses, and adding non-NULL counters to the
>> aggregates that then require them.
Hi,
On 2014-02-21 14:15:09 +0100, Christian Kruse wrote:
> +/* --
> + * pgstat_fetch_stat_local_beentry() -
> + *
> + * Like pgstat_fetch_stat_beentry() but with local addtions (like xid and
> + * xmin values of the backend)
s/local addtions/locally computed addititions/
> +/*
On Mon, Feb 24, 2014 at 9:08 AM, Merlin Moncure wrote:
> On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure wrote:
>> I still find the phrasing "as jsonb is more efficient for most
>> purposes" to be a bit off Basically, the text json type is faster for
>> serialization/deserialization pattern (not
Hi,
I took a quick peek at this, and noticed the following things:
* I am pretty sure this patch doesn't compile anymore after the latest
set of releases.
* This definitely should include isolationtester tests actually
performing concurrent ALTER TABLEs. All that's currently there is
tests t
On Wed, Feb 19, 2014 at 1:39 PM, Marti Raudsepp wrote:
> On Wed, Feb 12, 2014 at 11:54 PM, Marti Raudsepp wrote:
>> With partial-sort-basic-1 and this fix on the same test suite, the
>> planner overhead is now a more manageable 0.5% to 1.3%; one test is
>> faster by 0.5%.
>
> Ping, Robert or anyo
On Wed, Feb 19, 2014 at 06:37:42PM -0500, Tom Lane wrote:
> Emre Hasegeli writes:
> > [ cites bug #5705 ]
>
> Hm. I had forgotten how thoroughly broken btree_gist's inet and cidr
> opclasses are. There was discussion at the time of just ripping them
> out despite the compatibility hit. We didn
2014-02-23 22:24 GMT+09:00 Kohei KaiGai :
> Folks,
>
> Let me remind the custom-scan patches; that is a basis feature of
> remote join of postgres_fdw, cache-only scan, (upcoming) GPU
> acceleration feature or various alternative ways to scan/join relations.
> Unfortunately, small amount of discuss
Hi Kaigai-san,
Sorry to leave the thread for a while.
2014-02-23 22:24 GMT+09:00 Kohei KaiGai :
> (1) Interface to add alternative paths in addition to built-in join paths
>
> This patch adds "add_join_path_hook" on add_paths_to_joinrel to allow
> extensions to provide alternative scan path in ad
On Wed, Feb 19, 2014 at 8:27 PM, Michael Paquier
wrote:
> On Thu, Feb 20, 2014 at 8:55 AM, Andres Freund wrote:
>> On 2014-02-19 12:47:40 -0500, Robert Haas wrote:
>>> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
>>> wrote:
>>> >> Yes, that's a good precedent in multiple ways.
>>> > Here are
Hi,
attached you will find a new version of the patch, removing the ctid
text but leaving the ctid itself in the message.
On 23/02/14 11:14, Amit Kapila wrote:
> >> In general, why I am suggesting to restrict display of newly added
> >> context for the case it is added to ensure that it doesn't g
On 2014-02-23 20:04:39 +0100, Pavel Stehule wrote:
>354246.00 93.0% s_lock
> /usr/lib/postgresql/9.2/bin/postgres
> 10503.00 2.8% LWLockRelease
> /usr/lib/postgresql/9.2/bin/postgres
> 8802.00 2.3% LWLockAcquire
> /usr/lib/postgresql/9.2/bin/postgres
>
On Mon, Feb 24, 2014 at 8:46 AM, Merlin Moncure wrote:
> I still find the phrasing "as jsonb is more efficient for most
> purposes" to be a bit off Basically, the text json type is faster for
> serialization/deserialization pattern (not just document preservation)
> and jsonb is preferred when st
2014-02-23 21:32 GMT+01:00 Andres Freund :
> Hi,
>
> On 2014-02-23 20:04:39 +0100, Pavel Stehule wrote:
> > There is relative few very long ProcArrayLocks lwlocks
> >
> > This issue is very pathologic on fast computers with more than 8 CPU.
> This
> > issue was detected after migration from 8.4 to
On 2014-02-15 17:29:04 -0500, Robert Haas wrote:
> On Fri, Feb 14, 2014 at 4:55 AM, Andres Freund wrote:
> + /*
> +* XXX: It's impolite to ignore our argument and keep decoding until
> the
> +* current position.
> +*/
>
> Eh, what?
So, the background here is that
On Wed, Feb 19, 2014 at 8:06 PM, Michael Paquier
wrote:
> On Thu, Feb 20, 2014 at 9:43 AM, Michael Paquier
> wrote:
>> On Thu, Feb 20, 2014 at 2:47 AM, Robert Haas wrote:
>>> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
>>> wrote:
On Thu, Feb 6, 2014 at 3:48 AM, Peter Eisentraut wrote:
On Mon, Feb 24, 2014 at 12:20 AM, Josh Berkus wrote:
> All,
>
> Here's a draft cleanup on the JSON section of the Datatype docs. Since
> there's been a bunch of incremental patches on this, I just did a diff
> against HEAD.
>
> I looked over json-functions a bit, but am not clear on what needs to
Andres Freund escribió:
> On 2014-02-24 17:53:31 +0900, Michael Paquier wrote:
> > On Sun, Feb 23, 2014 at 6:09 AM, Alvaro Herrera
> > wrote:
> >
> > > Michael Paquier escribió:
> > > > Hi all,
> > > >
> > > > Please find attached a patch to dump pageinspect to 1.2. This
> > > > simply changes pa
Yes, the repository you mentioned is the last version of our
development. It contains various fixes of issues by Andres, but we are
waiting Andrew, who is working on jsonb stuff.
On Mon, Feb 24, 2014 at 5:34 PM, Tomas Vondra wrote:
> On 7.2.2014 00:47, Andrew Dunstan wrote:
>>
>> On 02/05/2014 10
On 7.2.2014 00:47, Andrew Dunstan wrote:
>
> On 02/05/2014 10:36 AM, Teodor Sigaev wrote:
>> Should I make new version of patch? Right now it's placed on github.
>> May be Andrew wants to change something?
>>
>
>
> Attached are updated patches.
>
> Apart from the things Teodor has fixed, this
From: "Rajeev rastogi"
Please find the attached modified patch.
Thanks, reviewed and made this patch ready for committer.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacker
On 2014-02-24 17:53:31 +0900, Michael Paquier wrote:
> On Sun, Feb 23, 2014 at 6:09 AM, Alvaro Herrera
> wrote:
>
> > Michael Paquier escribió:
> > > Hi all,
> > >
> > > Please find attached a patch to dump pageinspect to 1.2. This simply
> > > changes page_header to use the new internal datatype
On Sun, Feb 23, 2014 at 6:09 AM, Alvaro Herrera wrote:
> Michael Paquier escribió:
> > Hi all,
> >
> > Please find attached a patch to dump pageinspect to 1.2. This simply
> > changes page_header to use the new internal datatype pg_lsn instead of
> text.
>
> Uhm. Does this crash if you pg_upgrade
62 matches
Mail list logo
