[HACKERS] how to use advanced gist options

2010-03-14 Thread Sergej Galkin
Hello all,

Now I'm trying to realize index in GiST. Everything is Ok, but I would like
to know about advanced index programming options.
1) For example - can I delete entry in my picksplit procedure ?
2) Or to add logical conditions - when picksplit node ?  For exampe change
default "when number of entries of node is much than XX, split node" - to
"when number of entries which element "state" is "on" is much than XX, split
node ?"

Faithfully,
Sergej


Re: [HACKERS] Getting to beta1

2010-03-14 Thread Heikki Linnakangas
Simon Riggs wrote:
> I have these things on my list
> 
> * Minor page xid bug fix
> * btree delete standby-side derivation of xid
> * review of StartupXLog issue, on open items list, has an effect on HS
> 
> I expect to be finished with those by Wed, perhaps Thurs.

Don't forget the "start from shutdown checkpoint" issue.

> * There should be a default for "trigger_file" so that you can failover
> a server even if this has not been specified.

I disagree. In many cases, you never want to failover the standby, and
having a default would just get in your way.

> To me the open items look like at least 2 weeks work on SR, given some
> of them will likely need discussion rather than just action.

Yeah, I've unfortunately had very little to no time at all on SR
recently. I must reserve some full days for that again...

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Getting to beta1

2010-03-14 Thread Simon Riggs
On Sun, 2010-03-14 at 16:53 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I have these things on my list
> > 
> > * Minor page xid bug fix
> > * btree delete standby-side derivation of xid
> > * review of StartupXLog issue, on open items list, has an effect on HS
> > 
> > I expect to be finished with those by Wed, perhaps Thurs.
> 
> Don't forget the "start from shutdown checkpoint" issue.

How could I? :-)

> > * There should be a default for "trigger_file" so that you can failover
> > a server even if this has not been specified.
> 
> I disagree. In many cases, you never want to failover the standby, and
> having a default would just get in your way.

An explanation in the docs would be good. And also a hint of how to
failover if you decide in an emergency that the absence was a mistake,
in retrospect.

> > To me the open items look like at least 2 weeks work on SR, given some
> > of them will likely need discussion rather than just action.
> 
> Yeah, I've unfortunately had very little to no time at all on SR
> recently. I must reserve some full days for that again...

12 open items says "yes please" to that.

-- 
 Simon Riggs   www.2ndQuadrant.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] idle in txn query cancellation

2010-03-14 Thread Andres Freund
On Sunday 14 February 2010 06:29:45 Simon Riggs wrote:
> On Sat, 2010-02-13 at 22:37 +0100, Andres Freund wrote:
> > I know it is late in the cycle
> 
> No problem here. Thanks for your diligence. Will review.
Got a chance to look at it?

Andres

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] idle in txn query cancellation

2010-03-14 Thread Simon Riggs
On Sun, 2010-03-14 at 19:50 +0100, Andres Freund wrote:
> On Sunday 14 February 2010 06:29:45 Simon Riggs wrote:
> > On Sat, 2010-02-13 at 22:37 +0100, Andres Freund wrote:
> > > I know it is late in the cycle
> > 
> > No problem here. Thanks for your diligence. Will review.
> Got a chance to look at it?

I need to spend my time on ensuring we can avoid the cancellation
altogether, so I apologise for not reviewing. That's not a comment on
your work or the possible effectiveness of the patch. Possibly others
have the time to review?

-- 
 Simon Riggs   www.2ndQuadrant.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] [BUGS] PD_ALL_VISIBLE flag error on 9.0 alpha 4

2010-03-14 Thread Josh Berkus

> I can imagine and have done so. That patch was completed more than 6
> weeks ago and can still be included in this release.

See, this is why you're a committer and I'm not. ;-)

> http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg145951.html

Cool!  Will test.  We'll make this thing work yet!

It would be a very different PostgreSQL without you, Simon.  Thanks for
all the hard work.

--Josh Berkus

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Getting to beta1

2010-03-14 Thread Josh Berkus
On 3/14/10 9:02 AM, Simon Riggs wrote:
> An explanation in the docs would be good. And also a hint of how to
> failover if you decide in an emergency that the absence was a mistake,
> in retrospect.

I'm planning on writing a "Guide to HS & SR" for the beta.  Originally I
planned to put this in the main docs, but I couldn't figure out how to
fit it in there structurally.  Plus, it needs more examples, output
samples, and a tutorial feel.

--Josh Berkus

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Getting to beta1

2010-03-14 Thread Josh Berkus
Devs,

Also, I would like to have a Beta or at least a new alpha release before
April 3 for the test-fest, so that our volunteers aren't testing bugs
which are already patched.

--Josh

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Getting to beta1

2010-03-14 Thread David E. Wheeler
On Mar 14, 2010, at 3:38 PM, Josh Berkus wrote:

> I'm planning on writing a "Guide to HS & SR" for the beta.  Originally I
> planned to put this in the main docs, but I couldn't figure out how to
> fit it in there structurally.  Plus, it needs more examples, output
> samples, and a tutorial feel.

Perhaps a tutorial could go under Server Administration? Or perhaps under 
Tutorial even? It would be section I.4.

  http://developer.postgresql.org/pgdocs/postgres/index.html

Frankly, I think more examples and tutorials in the docs would help newbies a 
*lot*.

Best,

David


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Assertion failure twophase.c (3) (testing HS/SR)

2010-03-14 Thread Erik Rijkers
On Thu, March 4, 2010 17:00, Erik Rijkers wrote:
> in a 9.0devel, primary+standby, cvs from 2010.03.04 01:30
>
> With three patches:
>
>   new_smart_shutdown_20100201.patch
>   extend_format_of_recovery_info_funcs_v4.20100303.patch
>   fix-KnownAssignedXidsRemoveMany-1.patch
>
>   pg_dump -d $db8.4.2 | psql -d $db9.0devel-primary
>
> FailedAssertion, File: "twophase.c", Line: 1201.
>

For the record, this still happens (FailedAssertion, File: "twophase.c", Line: 
1201.)
(created 2010.03.13 23:49 cvs).

Unfortunately, it does not happen always, or predictably.

patches:
 new_smart_shutdown_20100201.patch
 extend_format_of_recovery_info_funcs_v4.20100303.patch
 (both here: http://archives.postgresql.org/pgsql-hackers/2010-03/msg00446.php )

  (fix-KnownAssignedXidsRemoveMany-1.patch has been committed, I think?)


I use commandlines like this to copy schemas across from 8.4.2 to 9.0devel:
pg_dump -c -h /tmp -p 5432 -n myschema --no-owner --no-privileges mydb \
  | psql -1qtA -h /tmp -p 7575 -d replicas

(the copied schemas were together 175 GB)

As I seem to be the only one who finds this, I started looking what could be 
unique in this
install: and it would be postbio, which we use for its gist-indexing on ranges
(http://pgfoundry.org/projects/postbio/).  We use postbio's int_interval type 
as a column type. 
But keep in mind that sometimes the whole dump+restore+replication completes OK.


Other installed modules are:
  contrib/btree_gist
  contrib/seg
  contrib/adminpack

log_line_prefix = '%t %p %d %u start=%s ' # slave

pgsql.sr_hotslave/logfile:

2010-03-13 23:54:59 CET 15765   start=2010-03-13 23:54:59 CET LOG:  database 
system was
interrupted; last known up at 2010-03-13 23:54:31 CET
cp: cannot stat 
`/var/data1/pg_stuff/dump/hotslave/replication_archive/00010001':
No such file or directory
2010-03-13 23:55:00 CET 15765   start=2010-03-13 23:54:59 CET LOG:  entering 
standby mode
2010-03-13 23:55:00 CET 15765   start=2010-03-13 23:54:59 CET LOG:  redo starts 
at 0/120
2010-03-13 23:55:00 CET 15765   start=2010-03-13 23:54:59 CET LOG:  consistent 
recovery state
reached at 0/200
2010-03-13 23:55:00 CET 15763   start=2010-03-13 23:54:59 CET LOG:  database 
system is ready to
accept read only connections
TRAP: FailedAssertion("!(((xid) != ((TransactionId) 0)))", File: "twophase.c", 
Line: 1201)
2010-03-14 05:28:59 CET 15763   start=2010-03-13 23:54:59 CET LOG:  startup 
process (PID 15765)
was terminated by signal 6: Aborted
2010-03-14 05:28:59 CET 15763   start=2010-03-13 23:54:59 CET LOG:  terminating 
any other active
server processes


Maybe I'll try now to setup a similar instance without postbio, to see if the 
crash still occurs.

hth,

Erik Rijkers



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers