04.05.2011 0:00, Alvaro Herrera пишет:
Excerpts from Зотов Роман's message of mar may 03 16:31:31 -0300 2011:
but here we can see problem like
F(smallint)
F(integer)
but call like F(float)
i wouldn`t like to fail it.
I think this particular example would be a mistake, because that cast
would b
On Tue, 03 May 2011 12:40:28 -, Andrew Dunstan
wrote:
Our Makefiles use dlltool and dllwrap to create DLLs. If you used our
recommended build method pgxs would do lots of the work for you.
I'm not sure why you asked the mingw-w64 team about building a Postgres
extension - they are un
Andrew Dunstan writes:
> On 05/03/2011 09:53 PM, David Blewett wrote:
>> On Tue, May 3, 2011 at 9:51 PM, David Blewett wrote:
>> That should read: ... but maybe it'd be easiest to take it a step
>> further and have an additional, automatically created patch file that
>> is run through pgindent wh
On 05/03/2011 09:53 PM, David Blewett wrote:
On Tue, May 3, 2011 at 9:51 PM, David Blewett wrote:
This seems like a pretty good idea, but maybe it'd be easiest to take
it a step further and add an "automatic pgindent-ified" patch is
created when a patch is added to the commitfest app?
That s
Kevin Grittner wrote:
Check where the plan goes from a table scan to an indexed access.
Also look at what is showing for SIRead locks in pg_locks as you go.
Between those two bits of information, it should become apparent.
OK, so this doesn't look to be an index lock related thing at all here.
Jaime Casanova writes:
> I want to propose the addition of a new field in IDENTIFY_SYSTEM:
> xlogversion, which will carry XLOG_PAGE_MAGIC from primary.
> The idea of sending that info is to allow us to know if the xlog page
> version of two different major versions are compatible or not.
> Curren
Kevin Grittner wrote:
I don't think Vlad is being unreasonable here; he's provided a
test case demonstrating the behavior he'd like to see, and shown
it doesn't work as expected.
... on a toy table with contrived values. How different is this
from the often-asked question about why a que
Josh Berkus writes:
> So, some data:
> corp=# select * from public.pgstattuple('idx__listings_features');
> -[ RECORD 1 ]--+-
> table_len | 54190080
> tuple_count| 7786
> tuple_len | 2117792
> tuple_percent | 3.91
> dead_tuple_count | 0
> dead_tuple_le
On Tue, May 3, 2011 at 9:51 PM, David Blewett wrote:
> This seems like a pretty good idea, but maybe it'd be easiest to take
> it a step further and add an "automatic pgindent-ified" patch is
> created when a patch is added to the commitfest app?
That should read: ... but maybe it'd be easiest to
Greg Smith wrote:
> However, if I increase the generate_series to create 349 rows (or
> more) instead, it works.
> I don't fully understand why this attempt I tried to do that is
> working the way it does though.
Check where the plan goes from a table scan to an indexed access.
Also look at w
On Mon, May 2, 2011 at 2:01 AM, Pavan Deolasee wrote:
> Can we not setup a automatic mechanism where a submitter can send a patch to
> some email id, the patch gets applied on the current HEAD, pgindent is run
> and the new patch is sent back to the submitter who can then submit it to
> the hacker
Hi guys,
No matter I turn on or turn off the "full_page_writes", I always
observe 8192-byte writes of log data for simple write operations
(write/update).
But according to the document, when this is off, it could speed up
operations but may cause problems during recovery. So, I guess this is
beca
Dan Ports wrote:
Yes, you're right -- the current implementation of SSI only locks
indexes at the granularity of index pages. So although those
transactions don't actually access the same records, they're detected
as a conflict because they're on the same index page.
Let's try to demonstrate th
On Tue, May 3, 2011 at 6:32 PM, Andres Freund wrote:
>
> I can't see xlog replication working between major versions.
well, probably... but not many years ago we wouldn't see integrated
replication in postgresql... still, here we are...
it's a difficult problem to solve? surely. we can make it wo
All,
Some trending data, since there's a lot of bloated indexes here:
select 'index_' || ( row_number() over ( order by free_percent desc ) )
as "index", *
from (
select (public.pgstattuple(indexname::text)).free_percent,
round(( n_tup_upd )::numeric / n_tup_ins, 2) as update_ratio,
round(( n_tup
Hi,
On Wednesday, May 04, 2011 12:39:49 AM Jaime Casanova wrote:
> I want to propose the addition of a new field in IDENTIFY_SYSTEM:
> xlogversion, which will carry XLOG_PAGE_MAGIC from primary.
> The idea of sending that info is to allow us to know if the xlog page
> version of two different majo
Hi
I want to propose the addition of a new field in IDENTIFY_SYSTEM:
xlogversion, which will carry XLOG_PAGE_MAGIC from primary.
The idea of sending that info is to allow us to know if the xlog page
version of two different major versions are compatible or not.
Currently pg_upgrade requires the pr
Tom, Alexander,
So, some data:
corp=# select indexname,
pg_size_pretty(pg_relation_size(indexname::text)) as indexsize,
pg_size_pretty(pg_relation_size(tablename::text)) as tablesize
from pg_indexes where indexname like '%__listings_features' order by
pg_relation_size(indexname::text) desc;
On Tue, May 3, 2011 at 4:54 PM, Tom Lane wrote:
> Simon Riggs writes:
>> You're assuming that there are referential links *from* other tables
>> to the table with damage. In which case you would be correct. But of
>> course, if you needed that data for integrity you would never do that,
>> so the
Simon Riggs writes:
> You're assuming that there are referential links *from* other tables
> to the table with damage. In which case you would be correct. But of
> course, if you needed that data for integrity you would never do that,
> so the problem is a nonexistent use case. The suggested mode
All,
I've added a check box giving permission to forward failure reports to
pgsql-bugs.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
On Tuesday, May 03, 2011 10:33:03 PM Alvaro Herrera wrote:
> Excerpts from Josh Berkus's message of mar may 03 16:59:54 -0300 2011:
> > Hackers,
> >
> > And we have our first useful test reports. Please see these tests:
> >
> > 5/3/2011 8:01:29 -- issue with escaping quotes in functions.
>
> Is
Excerpts from Josh Berkus's message of mar may 03 16:59:54 -0300 2011:
> Hackers,
>
> And we have our first useful test reports. Please see these tests:
>
> 5/3/2011 8:01:29 -- issue with escaping quotes in functions.
Is this about standard_conforming_strings flipping default?
--
Álvaro Herre
> The HowToBetaTest guide only refers to that app. Not to anything else.
> *At least* it should instruct people sending bugs additionally to pgsql-
> bugs/the web form.
It's a wiki; feel free to add it.
BTW, I'll point out to everyone that I posted my idea to do this more
than 2 weeks ago. So i
On Tue, May 3, 2011 at 8:21 PM, Simon Riggs wrote:
> The current assessment is that UNLOGGED tables are useful only for
> running a data cache. If the database crashes, then the table is
> truncated and you must refill the cache. If that is the case, then it
> must surely be better to have a cache
On Tuesday, May 03, 2011 10:25:13 PM Josh Berkus wrote:
> >> Are we really running a Google spreadsheet as in effect a bug tracker?
> >
> >
> >
> > And why are we so inistant on not posting bug reports to pgsql-bugs?
>
> We're not. However:
The HowToBetaTest guide only refers to that app. Not to
>> Are we really running a Google spreadsheet as in effect a bug tracker?
>
> And why are we so inistant on not posting bug reports to pgsql-bugs?
We're not. However:
a) pgsql-bugs doesn't help us to get all of the various test information
without a lot of back-and-forth with the submitter (pl
On Tuesday, May 03, 2011 10:06:08 PM Magnus Hagander wrote:
> On Tue, May 3, 2011 at 22:03, Andrew Dunstan wrote:
> > On 05/03/2011 03:59 PM, Josh Berkus wrote:
> >> Hackers,
> >>
> >> And we have our first useful test reports. Please see these tests:
> >>
> >> 5/3/2011 8:01:29 -- issue with es
On Tue, May 3, 2011 at 8:59 PM, Josh Berkus wrote:
>
> Also, Dave, there's a complaint about the one-click packages:
pgsql-b...@postgresql.org please.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Compan
On Tue, May 3, 2011 at 22:03, Andrew Dunstan wrote:
>
>
> On 05/03/2011 03:59 PM, Josh Berkus wrote:
>>
>> Hackers,
>>
>> And we have our first useful test reports. Please see these tests:
>>
>> 5/3/2011 8:01:29 -- issue with escaping quotes in functions.
>>
>> 5/3/2011 11:06:16 -- core dump with
On 05/03/2011 03:59 PM, Josh Berkus wrote:
Hackers,
And we have our first useful test reports. Please see these tests:
5/3/2011 8:01:29 -- issue with escaping quotes in functions.
5/3/2011 11:06:16 -- core dump with pg_restore
Also, Dave, there's a complaint about the one-click packages:
Excerpts from Зотов Роман's message of mar may 03 16:31:31 -0300 2011:
> but here we can see problem like
> F(smallint)
> F(integer)
> but call like F(float)
> i wouldn`t like to fail it.
I think this particular example would be a mistake, because that cast
would be lossy, so you want to invoke i
Hackers,
And we have our first useful test reports. Please see these tests:
5/3/2011 8:01:29 -- issue with escaping quotes in functions.
5/3/2011 11:06:16 -- core dump with pg_restore
Also, Dave, there's a complaint about the one-click packages:
5/3/2011 8:04:02
(and yes, it's annouying that
03.05.2011 23:06, Tom Lane пишет:
I wrote:
Alvaro Herrera writes:
The interesting discussion is what happens next. To me, this is all
related to this previous discussion:
http://archives.postgresql.org/pgsql-hackers/2010-09/msg00232.php
Yeah, there doesn't seem like much point unless we have
On Tue, Apr 26, 2011 at 8:49 AM, Leonardo Francalanci wrote:
>> > If that 1% is random (not time/transaction related), usually you'd rather
>>have an empty table.
>>
>> Why do you think it would be random?
>
> "Heap blocks would be zeroed if they were found to be damaged, following a
> crash."
>
I wrote:
> Alvaro Herrera writes:
>> The interesting discussion is what happens next. To me, this is all
>> related to this previous discussion:
>> http://archives.postgresql.org/pgsql-hackers/2010-09/msg00232.php
> Yeah, there doesn't seem like much point unless we have a clear idea
> what we'r
On Tue, May 3, 2011 at 7:51 PM, Josh Berkus wrote:
> On 5/3/11 1:28 AM, Dave Page wrote:
>> On Mon, May 2, 2011 at 7:12 PM, Josh Berkus wrote:
>>> Hackers,
>>>
>>> I've replaced test-report-by-email with a GoogleDocs application for Beta1.
>>
>> Didn't we stop doing that when the buildfarm came a
Excerpts from Tom Lane's message of mar may 03 15:41:27 -0300 2011:
> Alvaro Herrera writes:
> > Excerpts from Зотов Роман's message of lun abr 11 17:39:32 -0300 2011:
> > I had a brief look at this patch, updating it to current HEAD past some
> > pgindent conflicts. It seems sane, but as Zotov s
On 5/3/11 1:28 AM, Dave Page wrote:
> On Mon, May 2, 2011 at 7:12 PM, Josh Berkus wrote:
>> Hackers,
>>
>> I've replaced test-report-by-email with a GoogleDocs application for Beta1.
>
> Didn't we stop doing that when the buildfarm came along?
This is user beta tests, not build tests. If you lo
Alvaro Herrera writes:
> Excerpts from ÐоÑов Роман's message of lun abr 11 17:39:32 -0300
> 2011:
> I had a brief look at this patch, updating it to current HEAD past some
> pgindent conflicts. It seems sane, but as Zotov says, it doesn't do
> anything yet: it only changes typispreferr
Just a quick status update.
I wrote:
> Consider this a WIP patch
The serializable branch on my git repo has a modified form of this
which has been tested successfully with:
DROP INDEX
REINDEX
VACUUM FULL
CLUSTER
ALTER TABLE
I'm holding off on posting another version of the patch until I
c
Dave Page writes:
> On Tue, May 3, 2011 at 10:33 AM, Susanne Ebrecht
> wrote:
>> When we make such a hint for foreign tables then we should make a similar
>> hint for views.
> A view really isn't a table, unlike a foreign table, so I don't think
> that argument holds.
Well, from the implementat
On 05/03/2011 06:45 AM, Johann 'Myrkraverk' Oskarsson wrote:
On Tue, 03 May 2011 09:32:29 -, Andrew Dunstan
wrote:
On 05/03/2011 02:46 AM, Johann 'Myrkraverk' Oskarsson wrote:
When compiling PG with mingw-w64 the PGDLLEXPORT macro is blank.
Here is a patch that "fixes it for me." If
On Tue, May 03, 2011 at 10:42:30AM +0100, Dave Page wrote:
> On Tue, May 3, 2011 at 10:33 AM, Susanne Ebrecht
> wrote:
> > On 03.05.2011 09:30, Magnus Hagander wrote:
> >>
> >> Well, yeah, but I don't think we can squeeze that into 9.1 without
> >> Robert noticing :P
> >>
> >> Any suggestions on *
Excerpts from David Fetter's message of lun may 02 17:53:35 -0300 2011:
> Please find attached a patch adding IDs to the appropriate (I think)
> spots.
Thanks. There are some ID missing on some sect2 still; I had a look
yesterday and the problem is that the subsection titles collide with the
sec
Dan Ports wrote:
> On Tue, May 03, 2011 at 01:36:36PM +0900, Vlad Arkhipov wrote:
>> Then I commited the both and the second one raised an exception:
>> ERROR: could not serialize access due to read/write dependencies
>> among transactions
>> SQL state: 40001
>>
>> However the second transaction d
On Tue, 03 May 2011 09:32:29 -, Andrew Dunstan
wrote:
On 05/03/2011 02:46 AM, Johann 'Myrkraverk' Oskarsson wrote:
When compiling PG with mingw-w64 the PGDLLEXPORT macro is blank.
Here is a patch that "fixes it for me." If this is correct, I'd
appreciate it will be applied to 9.0.x as
On Tue, May 3, 2011 at 10:33 AM, Susanne Ebrecht
wrote:
> On 03.05.2011 09:30, Magnus Hagander wrote:
>>
>> Well, yeah, but I don't think we can squeeze that into 9.1 without
>> Robert noticing :P
>>
>> Any suggestions on *what* the hint should be? Just something along the
>> line "indexes cannot
On 03.05.2011 09:30, Magnus Hagander wrote:
Well, yeah, but I don't think we can squeeze that into 9.1 without
Robert noticing :P
Any suggestions on *what* the hint should be? Just something along the
line "indexes cannot be created on foreign tables"?
Magnus,
I am not really sure if this is
On 05/03/2011 02:46 AM, Johann 'Myrkraverk' Oskarsson wrote:
Hi PostgreSQL Hackers,
When compiling PG with mingw-w64 the PGDLLEXPORT macro is blank.
Here is a patch that "fixes it for me." If this is correct, I'd
appreciate it will be applied to 9.0.x as well as HEAD.
AFAICT it's not bro
On Mon, May 2, 2011 at 7:12 PM, Josh Berkus wrote:
> Hackers,
>
> I've replaced test-report-by-email with a GoogleDocs application for Beta1.
Didn't we stop doing that when the buildfarm came along?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.en
On Mon, May 2, 2011 at 23:56, David Fetter wrote:
> On Mon, May 02, 2011 at 09:27:08PM +0200, Magnus Hagander wrote:
>> postgres=# DROP TABLE FOO;
>> ERROR: "foo" is not a table
>> HINT: Use DROP FOREIGN TABLE to remove a foreign table.
>> postgres=# CREATE INDEX baz ON foo(bar);
>> ERROR: "foo
52 matches
Mail list logo
